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@ Transaction execution system. 

(57) This invention relates to a transaction execution system. 
An embodiment of the invention provides a plurality of 
transaction terminals (1) in communication with a host data 
processing system (11). The terminals each include a 
keyboard (3), a display, document handling subsystems, a 
hardware control subsystem, a communication subsystem 
and a programmable control subsystem supervising the 
other subsystems. A user initiates a transaction request by 
inserting a card, which may have been issued by any of a 
plurality of cooperating card issuers or banks, into a card 
reader (2) of the terminals. The issuer identification number 
(9) is read from the card, and used to search a table (8) of 
card format and encryption key data. If the corresponding 
format and key data is located in the table, the terminal 
requests entry of a preassigned personal ID number (7) 
through the keyboard. Verification data located on the card 
by format data from the table is encrypted (5) in response to 
the key data from the table for comparison (6) with the 
keyboard entered ID number. If the corresponding format 
and key data is not located in the table, the card data is sent 
to the host (11), which accesses a master table 00} with the 
issuer identification number, and communicates back to the 
terminal the corresponding format and key data located in 
the master table. Once the terminal has checked for corres- 
pondence between encrypted verification data and the ID 
number, in response to format and key data from its own 



table or communicated. from the host, additional transaction 
data is obtained via the keyboard. Upon command from the 
host, the host supplied format and key data is purged by the 
terminal at completion of the transaction, or else retained for 
future reference. 
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TRANSACTION EXECUTION SYSTEM 

For reasons of public convenience and economy a variety 
of systems have been developed for executing user requested 
transactions. One example is a check cashing machine. Such 
a machine reads data from a check inserted therein and issues 
cash equal to the amount of the check if the check is found 
to be in order. Other systems have been developed for use in 
conjunction with credit cards. 

One credit card system stores credit card account inform- 
ation in a central data base. In response to the submission 
of an account number from a remote terminal r the system 
provides information relating to the account. For instance, 
the system may indicate that the card has expired, that it 
has been stolen or may indicate the dollar amount of available 
credit. After a transaction is completed, the system properly 
adjusts the stored information to account for the transaction. 

Other credit card systems, which are frequently used by 
banks to extend their services during times of heavy business 
or business closure, permit the issuance of cash or the 
receipt of deposits through a terminal. Such a terminal 
typically includes a mechanism for receiving and reading 
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information from a credit card, a keyboard, a display and 
document entry and exit apertures- The terminal may operate 
in conjunction with a data base or as a stand alone unit. 
Increased security for the issuance of cash without human 
intervention is attained by issuing a personal ID number with 
each credit card. A credit card transaction is then enabled 
only when an ID number corresponding to the account number 
read from the credit card is entered through the keyboard • 
This required correspondence prevents a thief or mere finder 
of a credit card from receiving cash from a terminal. If a 
terminal operates in conjunction with a data base the cor- 
respondence between account numbers and ID numbers can be 
chosen at random, but frequently the ID number is derivable 
from the account number in accordance with a predetermined 
code. In the latter situation, in order for the ID number to 
be chosen at random, such as by selection by the customer, an 
offset value is recorded on the card along with the account 
number, which offset. value is selected such that when added 
or otherwise combined with the ID number derived from the 
account number in accordance with the predetermined code, 
the result is the ID number chosen at random. These pre- 
determined relationships between ID number and account (and 
offset) data from the card permit a stand alone terminal to 
check the ID number, .by algorithmically relating the ID number 
to the account number. If credit cards issued by a plurality 
of cooperating banks are to be usable in a given terminal, 
all such banks must use the same code or algorithm, or other- 
wise provide for distinguishing the. algorithmic relationship 
used in issuing ID numbers from account data. In one such 
system, each terminal is provided with an identical table of 
pseudo-random numbers which is pseudo-randomly addressed, 
first with the institution identifier and then by a logical 
combination of the output of the table with digits of the 
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account number, m such a system, cards may be used which 
have been issued by various banks, but personnel of each bank 
has access in its terminals to the exact algorithm used by all 
other banks, and with knowledge of the bank identifier code 
can easily reconstruct ID numbers, m another system, a key- 
driven algorithm is provided for determining the relation 
between ID numbers and account numbers, in such a system, the 
account number and key number are combined using linear and 
non-linear operations to generate a check number for compari- 
son with the ID number. U.S. Patent 3,956,615 is such a 
system. For cards issued by different banks to be used in the 
same terminals, however, all banks must use the same key 
number, and the account number must be located in the same 
field on all cards. In one improvement on the system of u S 
Patent 3,956,615, a table of encrypted keys is maintained In' 
each terminal, containing the keys required for use in the 
key-driven algorithm for a plurality of cooperating banks 
together with data specifying the location on the card data 
track of account, offset, and other data to be used in gener- 
ating the check number for comparison with the ID code entered 
at the keyboard. However, this system is bound by storage 
limitations on the size of such a table, and each terminal is 
able to operate with cards issued only by a few of the poten- 
tial cooperating institutions. Further, this system cannot 
accommodate cards for different types where institution ID and 
card status are identical - such as may occur when a bank is 
migrating its issued card base between two different plans. 

While this table derived key driven credit card and id 
number identification technique improves the security of cash 
issue terminals and permits a plurality of banks to cooperate 
m honouring cards issued by the others, there are still 
weaknesses that may be exploited to gain access to the large 
amounts of cash that are stored in the terminal or available 
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in the accounts of cooperating banks for inter-fund transfer 
by operation of the terminal. One serious problem relates to 
the security of the encryption algorithm for terminals which 
are capable of stand alone operation, or even on-line oper- 
ation. A large number of operators or maintenance personnel 
are required for the day-to-day support of cash issue terminals. 
For example, one or two people at each branch bank location 
may have internal access to the cash issue terminals. Often 
times these people may have access to the encryption key for 
normal maintenance. Alternatively, with only a little train- 
ing, these people could learn to acquire the key by measuring 
electrical signals on the internal circuitry. Once an encryp- 
tion key is acquired, and if the algorithm is known, a cor- 
respondence between, a large number of . account numbers and ID 
numbers could be generated.. Then, with knowledge of the card 
format and location of verification, and offset data on the 
card, correspondence between card data and random chosen ID 
numbers can be ascertained. 

Another possible security problem arises from the 
transmission of account information and ID information between 
a terminal and a host data base.. These transmissions often 
involve utility communication lines and are therefore subject 
to monitoring by a large number of people. Encryption is 
often used to improve communication, security but anyone who 
is able to break the code or gain access to the code would be 
able to extract and compile a list of correspondence between 
credit card account information and ID numbers by monitoring 
these transmissions. In addition, by generating fake terminal 
communication traffic a person might gain access to the host 
data base and fraudulently transfer funds within data base 
accounts . 
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According to the present invention there is provided a 
transaction execution system comprising a transaction terminal 
for approval of a transaction and a host data processing 
system in communication with the terminal, characterised in 
that the host data processing system includes host storage 
means for storing a plurality of issuer unique control 
blocks each including an encryption key, and in that the 
terminal comprises terminal storage means for storing a 
lesser plurality of issuer unique control blocks each includ- 
ing an encryption key, card reader means for reading encoded 
data on an identification card presented to the terminal by 
an individual, the encoded data including issuer identi- 
fication data and card verification data, means responsive 
to the issuer identification data for searching the terminal 
storage means for a corresponding control block, means for 
communicating the encoded, data to the host when a corres- 
ponding control block is not found in the terminal storage 
means and for receiving from the host a corresponding control 
block for writing into the storage means, and means responsive 
to the encryption key data from the corresponding control 
block for encrypting the card verification data to generate 
a card check number. . 

A transaction execution system in accordance with an 
embodiment of the invention includes a host data processing 
system having a data base of stored, information for many 
accounts and a plurality of transaction terminals, in each 
terminal a table of encryption keys and card format inform- 
ation is maintained for a plurality of card issuers, which 
terminal table is searched in response to the issuer ID read 
from identification card presented to the terminal by an 
individual seeking authorization to perform a transaction. 
If the issuer ID is not found in the terminal table, the 
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terminal communicates the card data to the host, which 
performs a similar search of the master table. The master 
table entry for the issuer is communicated to the terminal 
from the host for use in the transaction , and then may be 
purged from the terminal table. The host may also check a 
file of consumer information and instruct the terminal to 
retain the card, terminate the transaction, or take other 
action as indicated by that information. Further, the local 
host may communicate with yet another remote host to prime 
the local host data base with consumer information in anti- 
cipation of a transaction request from the terminal. 

The encryption keys are stored in both the host and 
terminal tables in encrypted form, and double encrypted for 
communication . 

The table of encryption keys and card format may be 
further accessible in response to card track status as 
determined by the terminal card reader. 

An embodiment of the invention will now be described 
with reference to the accompanying drawings, wherein :- 

Figure 1 is a functional block diagram representing a 
transaction execution system in accordance with the invention; 

Figure 2 is a functional- block diagram representation 
of a transaction terminal used in the transaction execution 
system shown in Figure 1; 

Figure 3 is an operational block diagram representation 
of the manner in which . a user initiated transaction request 
is initially processed by a transaction terminal; 
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Figure 4 is a functional block diagram representation of 
subhost/ remote host data processor used in the transaction 
execution system shown in Figure 1; 

Figure 5 is a f unctional block diagram representation of 
the transaction execution system, showing the communication 
messages between the transaction terminal and host or subhost 
data processor in the course of a typical transaction; 

Figure 6 is a functional block diagram representation of 
a Financial Institution Table stored in the transaction 
terminal and host/subhost data processor; 

Figures 7A and 7B are an operation flow chart represent- 
ation of the steps performed by the transaction terminal; 

Figure 8 is an operational flow chart of the Search FIT 
step of Figure 7, illustrating also the steps performed in 
Searching the subhost financial institution table of Figure 
4 ; and 

Figure 9 is an operational flow chart of the Collect 
VPIN Data step of Figure 7. 

Referring to Figure l f there is shown a system for 
authorizing a plurality of individuals to operate automatic 
teller machines or the like using personal identification 
cards issued by a plurality of banks or other card issuing 
authorities. Each terminal is provided with a Financial . 
Institution Table (FIT) containing, encryption keys for use in 
the verification of correspondence between data read from the 
identification card and that entered by the individual at a 
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keyboard. The FIT is made virtually unlimited in size by 
providing access by the terminal to a master FIT at the host 
CPU when a card is presented at the terminal issued by an 
authority not having an entry in the terminal FIT. 

Te rmin al 1 is, for example, one of. a plurality of geo- 
graphically dispersed automatic teller machines (ATM) in an 
interchange system. In such a system, a plurality of banks 
agree to honour in their own respective ATM' s cards issued by 
the other banks. 

An individual desiring to perform a banking transaction 
at ATM 1 inserts a magnetic encoded card into card reader 2 
and enters his personal identification number (PIN) at key- 
board 3. Account number 4, or other specified validation 
data', read from the cud is converted by encryption logic 5 
into a number which is checked at compar ator 6 for corres- 
pondence with PIN 7. If . this, and/or other: checks are satis- 
fied, the individual ds permitted to proceed with the desired 
transaction. 

Each bank, in issuing to its customers their identi- 
fication cards and PINs, uses different PIN keys k, , k~,...k . 
*A PIN key is a multi^bit number used by the encryption logic 
in deriving from, say, an account number, a corresponding 
PIN. A subset of these PIN key k^ k 2 ,...k n (for n banks or 
different pi cms) is stored in FIT 8, a table within the 
terminal address space of storage which is searched or other- 
wise accessed by a bank identifier field 9 read by card 
reader 2, together with a track status designation, as will 
be explained more fully hereafter. Master FIT 10 for all 
banks or plans, is maintained at host CPU 11 and is accessed 
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by terminal 1 when its FIT 8 does not contain an entry cor- 
responding to bank ID 9 read from the ID card of an individual 
requesting authorization to complete a transaction. Host 11 
verifies that bank ID 9 corresponds to that of an interchange 
member, and communicates its fit 10 entry to terminal 1, 
which may store that information, say, at location N, for use 
in the present and subsequent transactions. Host 11 may be 
an IBM 3601 Communication Controller for the 3600 Financial 
System, or a general purpose computer such as the IBM System/ 
370 — or any combination of hosts and subhosts, as will be 
more fully explained. 

As will be described hereafter, FIT tables 8 and lo may 
include much more information ~ thus giving each bank M the 
flexibility of defining not only unique PIN keys, but also 
card formats, and authorization and transaction parameters . 

Referring now to Figure 2 , the transaction, terminal -is 
an improvement with respect to that described in U.S. Patent 
3,956,615. Figure 2 of U.S. Patent 3,956,615 is repeated 
herein for ease of reference as Figure 2 of the present 
application. Reference is made to U.S. Patent 3,956,615 for 
a detailed description of Figure 2. while the particular 
manner in which the transaction terminal 1 is implemented is 
not critical to the practice of this invention, a preferred 
embodiment is shown in Figure 2. Terminal. 1 is generally 
modular in nature and includes a programmable microprocessor 
60 coupled to a plurality of terminal subsystems by an inform- 
ation bus 62. Microprocessor 60 is driven by a clock signal 
from clock generator 64 and is operationally connected to a 
data storage module 66 providing both electrically alterable 
random access memory (RAM) and read only storage (ROS) . The 
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read only storage portion of data storage 66 stores the 
various operating programs for the microprocessor 60. The 
random, access memory portion of data storage module 66 provides 
a scratchpad for program execution, the storage of Keys and 
the FIT table lO. Reference is made to U.S. Patent 3,956,615 
for a description of the operational characteristics of 
processor support system 68, mechanical control subsystem 70, 
user communication subsystem 72, dispenser subsystem 74, 
operator function subsystem 76, and communication subsystem 
78. 

In the transaction authorization system, during the 
execution of a user transaction request, six communication 
messages between the terminal and the host may be required. 
These are explained in connection with Figures 3-5, and are 
the following: 

VFIT TRANSACTION REQUEST 

VFIT REPLY 

VFIT STATUS 

TRANSACTION REQUEST 

REPLY 

STATUS 

The transaction request, reply, and status messages are 
similar to those described in U.S. Patent 3,956,615, modified 
as will be described. The VFIT messages are substantially 
the same as the latter three, and are employed when trans- 
action terminal 1 must communicate with host 11 to obtain a 
FIT entry. 
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The transaction execution system is adapted to support 
the Track 2 magnetic stripe identification card format of 
the American Bankers Association and/or Thrift Industry 
Association and the Track 3 Magnetic Card Format as proposed 
by International Standards Organization (i S0 ) . The particular 
encryption algorithm which determines the correspondence 
between ID numbers and credit card information is not critical 
to the practice of the invention, except that that correspond- 
ence should be dependent on an encryption key. whereas the 
encryption algorithm described in U.S. Patent 3,956 515 is 
designated Lucifer, the present system is adapted for use 
with the U.S. National Bureau of Standards "Encryption 
Algorithm for Computer Data Protection", Federal Register 
Vol. 40, No. 52, Monday, March 17, 1975 (hereinafter referred 
to as DES. ) 

TRANSACTION REQUEST MESSAGE 

To the Transaction Request Message described in u S 
Patent 3,956,615, the following expanded function is provided 
in connection with the present system. This message now 
accommodates the transmission of T-3 as well as T-2 card 
data along with the normal transaction information sent to 
the host/subhost for transaction processing. A message flag 
byte and PIN retry byte are added to flag special conditions 
detected by the terminal. T-2 and T-3 represent two separate 
data tracks on the magnetic stripe of an identification card 
readable by card reader 2. 

Either or both T-2 and T-3 data may be transmitted in a 
Transaction Request. A data map field describing which T-3 
fields to transmit as well as information on which tracts to 
send is found in an Issuer's PIN Table entry. The following 
data is included in a Transaction Request Message: 
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Message header 

L - indicates the message length, including 

the L field, 
N - indicates the transaction sequence number. 
C - indicates the message class/subclass 

(Transaction Request/normal or VFIT 

Transaction) . 

Variable Field (VAR) 

Sum of rollover bill counter for cash withdrawal 

requests; otherwise, transaction sequence number. 
Consumer PIN 

The PIN entered by the consumer, or customer. 
From Account Field 

The from-account field set from the consumer 
. keyboard entry. 
To Account Field 

The to-account field set from the consumer keyboard 

entry. 

Special Transaction Number Field 

Amount Field 

Bill Mix Field 

T-2 Card Data 

Message Flag 

Bit 0 T-2 is good. 

1 T-3 is good. 

2 PIN retry count limit reached. 

3 PIN retry override failure. An Incomplete 
Transaction Request is sent with this bit set 
in the event of failure to enter correct PIN. 

4 Switch irregularity, indicating possible tanker- 
ing with the card if switch irregularities are 
detected while the ID card is parked at the 
back of the card reader transport. 
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5 PIN Unchecked Flag, set whenever the terminal 
does not perform pin verification. 

6 Two Track card, indicating both tracks 2 and 3 
were detected on the id card. 

PIN Retry 

Indicates the number of attempts the customer 
has made to enter the correct PIN before 
meeting the limit allowed. 
T-3 Data Map 

Indicates which T-3 fields are being sent in 
the T-3 Card Data field, it is a copy of 
the T-3 Data Map found in the PIN Table entry for 
the ID Card of this transaction. 
T-3 Card Data 

T-3 card data is transmitted if it is read 
successfully and the PIN Table entry indicates 
that it should be sent. All or certain fields of 
the track information may be transmitted as directed 
by the PIN Table Entry T-3 Data Map. 

VFIT TRANSACTION REQUEST MESSAGE 

This special Transaction Request subclass (Message 
Header, byte'c, above) enables the terminal to make Virtual 
PIN Table entry requests of the host/subhost if the virtual 
PIN Table entry Institution option is selected (during 
initialization of the terminal at Initial Program Load, or 
IPL) . The option specified whether a Virtual pin entry 
request may be made and additionally specifies the amount of 
data to be sent for each track (T2, T3) selected. The 
host/subhost may respond by sending the appropriate pin 
Table entry. The VFIT Transaction Request Message includes 
the following fields: 
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Message Header 

Transaction Sequence Number 

Message Flag 

T-2 Data 

T-3 Data 

The Message Header and Message Flag fields are specified 
as above, for the Transaction Request Message. 

TRANSACTION REPLY MESSAGE 

The Transaction Reply Message enables the host/subhost 
to send T3 data to be written on the card, together with the 
action, display, and statement printer data. This message 
has the following fields: 

Message Header 
Counter 

The value of the rollover bill counters total. 
Action 

This byte specifies the action to be taken by the 
terminal, including the following: 

0 Display pre-defined user message 

1 Display user message supplied in the 
display data field 

2 Print statement (s) 

3 Card removal time-out 

4 Transaction is authorized 

5 Retain credit card 

6 User acknowledgment requested 

7 Write T-3 data 
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Quantity 1 

The number of bills to be issued from hopper #1. 
Zero, for a single hopper terminal. 
Quantity 2 

The number of bills to be issued (single hopper 
terminal) , or the number of bills to be issued 
from currency hopper #2. 
Display Data 

If present, contains the message data to be displayed. 
The message may either be the number of a predefined 
message or the text of a special message. 

Statement Data 

If present, contains data to be printed on the 
transaction statement — the number of a 
predefined message, or an actual message, or 
both. 

T-3 Data Length 

T-3 Data Map 

T-3 Data 

VFIT TRANSACTION REPLY MESSAGE 

This special Transaction Reply Message is to transmit 
the PIN Table entry when requested by the terminal. If the 
host/subhost cannot provide a PIN Entry, then the VFIT 
Transaction Reply will contain a null PIN Entry field. 
Otherwise, the PIN Entry provided will be retained in the 
terminal memory until a new entry is received unless bit 6 
of the action byte is set to 1. The PIN entry is encrypted 
in the communication key KEY C or KEY B. This message has 
the following fields: 



0003756 



9 



- 16 - 

Message Header 
Counter 

The rollover bill counters total maintained in the 
terminal and maintained by the host application 
program. 
Action 

0 Display pre-defined user message. 

1 Display user message supplied in the display 
data field. 

4 PIN entry included in message. 

5 Retain credit card. 

6 Purge PIN entry after processing. 
Counter 1 

Counter 2 
Display Data 
PIN Entry 

STATUS MESSAGE/VFIT STATUS MESSAGE 

The status messages are transmitted from the terminal 
to the host in response to the transaction reply messages, 
indicating the results of processing of data received in the 
reply messages. Various status bit definitions pertinent to 
the preferred embodiment of the invention relate to transaction 
processing irregularities and errors on a Virtual PIN Entry 
reply. Selected .fields included in the status messages are 
as follows: 

Message Header 

Transaction Sequence Number 

Counter 1 

Length of Data Field 
Counter 2 
Status Data 
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0 
1 
2 



T-3 Write Failure 
Switch irregularity 

Virtual PIN Table entry error. This bit is set 
if: 

1) the entry requested did not match 

the entry returned based on lssue r ID comparison 
and card type; 

2) the entry returned was too long; 

3) the value in the PIN length field is i ess 
than a given value; 

4) the entry returned had a length value of 0- 
or ' 

5) the entry had invalid field location speci- 
fications. 

3 T-3 data error. 

Referring now to Figure 3, an individual desiring to 
perform a transaction at terminal 1, inserts a magnetic 
encoded credit card into card reader 2. Data read from ^ 
card xs stored xn data storage 66, and utilized by micro- 
processor 60 to search. local FIT 8, provide validation data 
12 and of fset data 13 for use in generating pin check nunber 
15 and data for inclusion in transaction request message 16 
for transmxssxon to host 11 by communication subsystem 78. 

0": alS °' " ^ ti0e in ^ 

of the transaction, is instructed to enter his PIN 7 at 

keyboard 3 for comparison with PIN check number 15 by 

comparator 6 within microprocessor 60. 

After a consumer card has been entered properly into 
the card reader 2, the terminal 1 attempts to find a pin 
Table (FIT) entry for the card issuing institution ID rid 
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from the card so that information governing the transaction 
may be found and the next step of verifying the PIN entered 
by the consumer may be performed. 

Track processing by card reader 2 in cooperation with 
microprocessor 60 comprises reading, the credit card to 
determine if it is processable based on track status. When 
a consumer enters a card into card reader 2, the tracks are 
read and, if necessary, reread in order to determine a track 
status for each track. The status may be good, bad, or 
undetectable. A card is considered usable if at least one 
track has a status of good. 

Each unique, issuer of an interchange system provides a 
PIN key to be used for PIN validation and PIN encryption. 
These PIN keys are provided by interchange member institutions 
in unique PIN table 8 entries transmitted from host 11 to 
terminal 1 during initialization (IPL) . Alternatively, 
these entries may be held in host fit 10 (Fig. 4) for virtual 
PIN processing. 

The process steps followed by microprocessor 60 in 
searching local FIT 8 are set forth in Figure 8 . These same 
steps may be followed by the host 11 in responding to a 
request for VPIN processing. The PIN Table 8, 10 search is 
an attempt to find the PIN table entry that corresponds to 
the card entered by the consumer, provided the card is 
processable. The PIN. table search algorithm uses the Issuer 
Identifier (II) as a .search argument and the credit card 
track status as a qualifier. The search argument can include, 
in accordance with the ISO draft standard T3 format, up to 
20 contiguous digits including the card format ID, the in- 
dustry ID, the standard issuer ID, and the consumer's primary 
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account number. The FIT entry i B set forth in Figure 6 
described below, and is searched as follows, if the Entry 
Type specified in the PIN table, or FIT, does not match the 
card type (e.g., T -2 is good and T-3 is undetected on the 
credit card but the PIN Table entry is t-3 only, T-2 or T-3 
independent or T-2/T^3 combined) , the PIN table entry is 
skipped. If the card type matches the PIN table entry type 
the definition in the PIN table entry is used to locate card 
data to be compared with the issuer ID in the PIN table 
entry. If they do not match, then the process is repeated 
with the next pin table entry, when a match is found, the 
search is over and that PIN table 8 entry definition is used 
for the remainder of the consumer transaction processing. 
If a common entry is. not found for this card type and if the 
Virtual PIN table entry option is not specified, the search 
terminates with the last entry in the PIN table 8. if no 
match is found, the credit card is returned to the consumer. 

If a common (that is, corresponding) entry is not found 
xn FIT 8, and the Virtual pin table option, is specified for 
terminal 1, microprocessor 60 assembles a VFIT Transaction 
Request message 17 for transmission to host 11, which will 
search host FIT 10, assemble a VFIT reply message 18 including 
the FIT table entry 19 storage by terminal 1 in FIT 8 or 
some other region of data storage 60. Thus, before requesting 
a VPIN table entry from the host/subhost. 11, the VPIN entry 
saved internally from previous VPIN requests is checked for 
a match with the current. ID card, if no entry is found in 
host FIT 10, that fact is indicated by bit four of the 
action byte in the VFIT transaction reply message. 

After a PIN table 8 entry is found that corresponds to 
the consumer credit card data, the entry is examined to 
determine if pin validation is to be performed by the terminal 
1 or by the host 11. If host 11 pin validation is specified 
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track status is checked, below, but no further PIN processing 
is performed at terminal 1. If track status indicates a bad 
track and the PIN table entry specifies "reject cards with a 
bad track", the transaction is terminated, the card is 
returned to the consumer, and an appropriate message displayed. 
If the card has no bad tracks or if the PIN table entry 
specifies "process cards with a bad track", PIN processing 
proceeds. 

In encrypt algorithm 20, the encrypted PIN key from PIN 
table 8 is decrypted using ICey A to generate the PIN key for 
use in encipher step 5, described below. PIN check, or 
validation, data 12 and offset data 13 may be located any- 
where on either track T-2 or T-3. If terminal PIN validation 
is specified by the .PIN table entry, their location is 
described by the PIN table entry. 

PIN processing by terminal 1 involves a master key, 
(card data, data from the FIT entry selected for the card, 
and keyboard data entered by the customer.) The Master Key 
is sent to terminal 1 from host 11 in a Load Master Key 
command. If no Load. Master Key command, has been executed, 
the A Key, entered at the operator/CE panel 76, is used as 
the master key. Validation data 12 could be the customer's 
account number or any number the financial institution wants 
to use to identify the customer. Offset data is optional, 
and may be selected in such a way that the PIN to be entered 
by the customer and: the validation data may be specified 
independently . 

The following parameters from the FIT entry provide the 
length, displacement, and padding specifications for the 
card data; a decimalization table; and encryption key required 
to perform the PIN check: 
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VALDISP specifies the displacement of the validation 
data field from the first data digit of the card 
data 

VALLEN specifies the number of digits contained in the 
validation data field* 

VALPAD specifies the digit to be used to pad the valid- 
ation data. if it contains less than 16 digits. 

OFFDISP specifies the offset data field displacement 
from the first data digit of the card data. 

CHKLEN is a parameter which specifies the number of 
digits contained in the offset data field, the 
number of digits to be checked in the customer 
entered PIN, and the minimum, number of digits 
allowed in the customer entered PIN. 

DECTAB is a table of 16 decimal digits to be used to 
convert the enciphered validation data to a 
decimal number. 

EPINKEY is the encrypted PIN key (enciphered in the 
master key) which is to be used to encipher the 
validation data. 

The following data is entered from the keyboard 3: 

PIN is the personal identification number entered on 

the keyboard 3 by the customer. 
PIN Length is the number of digits in the customer 
entered PIN. 

Referring now to Figure 3, terminal 1 performs the off- 
host PIN check as follows; 

1. The validation data 12 is obtained from the card 
using VALDISP to find the location and VALLEN to determine 
the length. 
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2. If VALLEN, which, indicates the number, of digits in the 
validation data field, is less than 16,. validation data 12 
is padded in pad step 21 on the right to 16 digits using the 
digit specified by VALPAD to yield padded validation data 
22. 

3. A PIN Key is obtained in one of two ways: 

- If the EPINKEY (or, FIT Key) parameter is specified 
in the FIT table entry, the value in EPINKEY is 
deciphered using the master key* 

- If the EPINKEY parameter is not specified in the FIT 
table entry, the master key is used as the PIN key. 

4. Padded validation data 22 is encyphered by encipher 
algorithm 5 using the PIN Key to yield enciphered validation 
data 23. 

5. The enciphered validation, data 23 is converted to 
decimal digits in decimalize, routine. 24 using DECTAB to 
yield decimalized validation data 25. Each hexidecimal 
digit of the enciphered validation, data 23. is replaced by a 
decimal digit from DECTAB . The decimal digit selected is 
the digit whose displacement (0-15) , in DECTAB, corresponds 
with the value of the hexidecimal digit (0-F) being replaced 
in validation data 23. 

6. Offset data 13 is obtained from, the card using OFFDISP 
to find the location and CHKLEN to determine the length. If 
OFFDISP=255 (X'FF'), all zero digits are. used for the offset 
data. 
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7. In block 26 offset data 13 is aligned with the decimal- 
ized validation data 25 such that the left most digit of the 
offset data 13 is displaced zero or more digit positions to 
the right of the left most digit of the decimalized valid- 
ation data. The number of digit positions of this displace- 
ment is obtained by subtracting CHKLEN from the PIN Length. 

8. The offset data digits 13 are added, digit-by-digit , 
modulo 10, to the decimalized validation data digits 25 with 
which they have been aligned. The result is PIN check number 
15. 

9. The PIN check number 15 is compared in comparator 6, 
digit-by-digit, from the right with digits of the customer 
entered PIN 7. For a successful comparison all digits of the 
PIN check number 15 .must be the same as the corresponding 
digits of the customer entered PIN^ 7. If the customer 
entered PIN Length is greater than CHKLEN, the extra, left- 
most (first entered) digits of the customer entered PIN 7 are 
not checked: any digit, values are acceptable for these extra 
digits . 

If comparison 6 is successful, terminal 1 proceeds with 
the transaction by assembling data, and encrypting part of it 
into a transaction request message 16 to host 11. If com- 
parison 6 is not successful, terminal 1 allows the customer 
zero or more retries, as specif ied by the RETRY customization 
parameter. Terminal 1 may return the card and terminate the 
transaction, sending no message to host 11. Alternatively, 
Terminal 1 may send an Invalid PIN Transaction Request 
message to host 11, and await a transaction reply directing 
terminal 1 to return or retain the card and, perhaps, display 
a message to the customer. 
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Referring now to Figure 4, the host/subhost is illus- 
trated with respect to the processing of a VFIT transaction 
request 17 from terminal 1. VFIT transaction request message 
17 is decrypted, according to the procedure taught in con- 
nection with Figure 4 of U.S. Patent 3,956,615. Using track 
status and issuer identification, as previously discussed 
with respect to the search of local FIT table 8 (and in 
accordance with the procedure illustrated in Figure 8) , 
subhost data processor 11 searches subhost FIT 10 to locate 
the corresponding FIT entry 19 for encryption in encrypt 
algorithm 28 using communication Key B or C. Encrypt algor- 
ithm 28 may be implemented in application programming executed 
by subhost data processor 11, or by digital hardware logic in 
accordance with the Data Encryption Standard (DES) of the 
U.S. National Bureau. of Standards, as described, in Federal 
Register, Vol. 40, Mo. 52, Monday, March 17, 1975. 

Using customer account identification data provided in 
the track data from the ID card in VFIT transaction request 
message 17, subhost- data processor 11 may search its customer 
data files 29, and based upon information stored there 
instruct terminal 1 through an action bit in VFIT reply 
message 18 to retain the card, or terminate or approve the 
transaction. Similarly, subhost data processor may place' 
display data into VFIT reply message 18 from display message 
file 30. Encrypt algorithm 28 further encrypts a portion 31 
of VFIT reply message 18, which in the absence of the optional 
display data may result in double encryption of a portion of 
the FIT entry 19. As the PIN key stored in FIT table 10 has 
been previously encrypted using the master key, this results 
in a possible triple encryption of FIT entry 19 using two 
different keys. 
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Subhost data processor 11 may also be connected with 
host data processor 27, which may be central host for the 
bank, a central host for all members of an interchange 
system, or the host or subhost of another member of the 
interchange accessible by subhost 11 through an appropriate 
switching communication link. 



Subhost data processor 11 provides means for communi- 
cating a VFIT reply message 18 to terminal 1 including the 
corresponding entry in PIT 10 for the institution ID and 
track status obtained via VFIT transaction request message 
17. In parallel with processing of data in terminal 1 to 
generate a transaction request message, subhost 11 may access 
host data processor 27 to obtain the consumer file for loading 
into its customer data file 29 in anticipation of receipt of 
a transaction request from terminal. 1 for the . individual 
identified in the data previously communicated in the VFIT 
transaction request message. Thus, subhost data processor 11 
need only maintain customer data files for its own issued 
cards, or even merely .assemble, transaction data for its own 
customers into a customer data file 29 for subsequent batch 
processing into other account files, when the transaction 
request message is subsequently received from terminal 1 by 
subhost 11, all data .required to process the , request is 
available in its files 29 ~ whether there originally or 
obtained from host 27. 

By a further embodiment of the invention, the terminal 
FIT 8 could store entries for the various plans only of the 
bank which owns or otherwise controls, terminal 1, and all fit 
entries for cooperating banks maintained at host FIT 10 — 
thus enhancing the security of the system with respect to 
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access by tellers or others to the FIT 8. The FIT entry for 
a given bank need only be retained in terminal 1 during 
execution of a single transaction, and then purged therefrom. 

By a further embodiment of the invention, a bank may 
migrate, its issued card base from one plan to another. 
During such migration, it is common for cards having identi- 
cal institution ID and track status to pertain to two dif- 
ferent plans. Terminal 1, not having the facility to check 
other data in the encoded track, would be unable to distinguish 
therebetween. Under these circumstances, the issuing bank 
could require that its FIT entries only be maintained at 
subhost 11, requiring terminal 1 to communicate via VFIT 
transaction request messages to process all transactions 
requested by customers for that issuer. At subhost 11, 
application programming , is provided to check all or some 
other portion of data. read from the card for a field that 
identifies the plan, thus enabling, the subhost 11 to provide 
to terminal 1 the . appropriate FIT entry, together with a 
command to purge it from terminal 1 storage upon completion 
of the transaction. 

As will, therefore, be apparent from the above, terminal 
1 may be connected with host 11, which in turn may be a 
subhost connected to a further remote host 27 — allowing 
security of data and efficiency in processing and storage by 
distributing FIT tables 8, 10 and customer account files, 
such as file 29 to many locations. By priming data file 29 
with account data from. host 27 while replying to terminal 1 
with VFIT reply message. 18, host 11 is enabled to respond 
quicker to the anticipated transaction, request from terminal 
1. 
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Host 11 may be, for example, an IBM 3601 controller or 
an IBM System/370 data processing system. Host 27 may be an 
IBM System/ 370. Host 11 is referred to as a subhost when it 
is connected to a remote host 27 — otherwise as a host, in 
either case, the terms host and subhost may be used inter- 
changeably when used in the context of the interface to 
terminal 1. 

Referring now to Figure 6, the PIN table entry will be 
described. There are three basic types of pin Table entries: 
T-2 (T-2 only or T-2 independent) , T-3 (T-3 only or T-3 
independent), and T-2/T-3 combined. Entries can appear in 
any order in the table. Entries of different types may have 
the same Issuer ID although T-2 and T-3 independent are 
mutually exclusive from T-2/T-3 combined, in addition to 
these Entry types, a Common Pin Table Entry may be specified. 
The Common Entry, if. specified, is the last in the PIN Table 
and is used for credit cards for which no PIN Table Entry 
match has been found. The PIN Table Entry contains all 
information necessary for consumer ID verification except the 
location of the Issuer ID which is obtained from the custom- 
ization image, provided to terminal 1 by host 11 prior to any 
transactions. A separate subentry in FIT tables 8, 10 is 
required for each card type supported (T-2, T-3, T-2/T-3) . 
Following is a description of fields 41-49 of common portion 
40: 

Common Portion 



Length of 
entry 41 



Total length of pin entry 
including this byte. 
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Flags 42 



Bit 
Bit 
Bit 
Bit 
Bit 
Bit 



Bit 



Bit 



0=1 Track 2 only supported 
1=1 Track 3 only supported 
2=1 Track 2 ind. supported 
3=1 Track 3 ind. supported 
4=1 T-2/T-3 supported 
5=0 II is on track 2 
=1 II is on track 3, use 

only when bit 4=1 
6=0 Process a T-2/T-3 card 

with 1 bad track 
6=1 Reject card with 1 bad 

track, use only when 

bit 4=1. 



Issuer PIN 
length 43 



Max. PIN Length accepted by 
issuer. 

Minimum allowed is four. 



PIN check 
length 44 



Number of digits of PIN to be 
validated by terminal. If = 
0, no PIN verification is 
performed. 



Issuer PIN 
pad/Check 
pad digits 45 



Bits 0-3 = Pad digit to be 
used in the terminal, if the 
consumer entered PIN is less 
than 16 digits. To pad on the 
right, the consumer-entered 
PIN to 16 digits for DES 
encryption. 

Bits 4-7 = Pad digit to be 
used if the issuer-supplied 
PIN check data is less than 16 
digits. To pad on the right the 
PIN check data from the card to 
16 digits for DES encryption. 
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PIN Key 46 



Decimal Trans- 
lation Table 47 



Issuer ID 
Length 48 



An issuer provided key for use 
in PIN encryption and PIN 
validation. The PIN key is 
encrypted in the roaster key. 

An issuer-provided table used for 
PIN validation. Encryption of the 
credit card PIN check data produces 
16 hexadecimal, digits which must be 
converted to decimal digits. Each 
hexadecimal digit is replaced by 
the decimal digit whose position 
in this table (0-15) corresponds to 
the value (0-F) of the hexadecimal 
digit being replaced. The trans- 
lation is performed, offset values 
are then added, if required, to the 
translated results, and then a 
comparison is made of the calcu- 
lated PIN. and the consumer's PIN. 

Length of ID field in bytes. 



Issuer ID 49 



Contains an Issuer ID used for PIN 
table entry selection. An entire 
Issuer. ID field of x'FF' designates 
the Common PIN Table entry, it 
must be the last entry in the pin 
Table. 
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Following is a description of fields 51-54 of T-2 only 
portion and T-2 independent field 50: 



PIN offset 
& PIN check 
location 51 



Bits Or-3 = Number of field 
separators to PIN offset T-2. 
Bits 4-7 = Number of field separators 
to PIN check data, T-2* 



Issuer PIN 
Offset 

displacement 52 



Displacement from the field 
separator value, specified in 
field 10 of the PIN Entry, to the 
PIN offset on the track. If this 
field is X'FF r , no offset is 
applied. 



Issuer PIN check 
data 

displacement 53 



Displacement from the field 
separator value , specified in 
field 51 of the PIN Entry, to : 
the PIN check data on the card. 
Used as a basis for correlation 
with the PIN entered by the consumer. 



Issuer PIN check Length of PIN check data provided 
data length 54 on card. If less than 16 digits, 

pad digits are added on the right 
by the terminal, to provide an 8-- 
byte field for DES encryption. 

Following is a description of fields 91-97 of T-3 only 
portion and T-3 independent field 90: 



PIN offset and 
PIN check 
location 91 



Bits 0-3 = Number of field separa- 
tors to PIN offset, T-3. Bits 
4-7 = Number of field separators to 
PIN check data, T-3. 
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Issuer PIN 
offset dis- 
placement 92 



Displacement from the field separator 
value, specified in field 91 of the 
PIN Entry, to the PIN offset on the 
track. If this field is X'FF', no 
offset is applied. 



Issuer PIN 
check data 
displacement 93 



Displacement from the field separa- 
tor value, specified in field 91 of 
the PIN Entry, to the PIN check data 
on the card, used as a basis for 
correlation with the PIN entered 
by the consumer. 



Issuer PIN 
check data 
length 94 



T-3 pin Retry 
location 95 



T-3 PIN Retry 
displacement 96 



Length of PIN check data pro- 
vided on card. If less than 16 
digits, pad digits are added on the 
right by the terminal to provide 
an 8-byte field for DBS encryption. 

Bits 0-3 = Reserved. 
Bits 4-7 - Number of. field separa- 
tors to field on card containing 
T-3 PIN retry count. 

Displacement, of T-3 retry count 
within field on card. 



T-3 data map 97 



Indicates which fields in T-3 
are to be sent in the Transaction 
Request message. 
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Following is a description of fields 101-107 of T-2/T-3 
portion 100: 



PIN offset 
and PIN check 
location 101 



Bits 0-3 = Number of field separa- 
tors to PIN offset on track 
specified in field 102- Bits 4-7 
= Number of field separators to PIN 
check data on track specified in 
field 103. 



Issuer PIN 
offset dis- 
placement 102 



Bit 0 = PIN offset track location. 
Bits 1-7 = Displacement from the 
field separator value specified in 
field 101 of the PIN Entry, to the 
PIN offset on the track. If this 
field is X'FF 1 , no offset is 
applied. 



Issuer PIN 
check data 
displacement 103 



Bit 0 = PIN check data track 
location. Bits 1-7 = Displacement 
from the field separator value, 
specified in the field 101 of the 
PIN Entry, to the PIN check data 
on the card. Used as basis for 
correlation with the PIN entered 
by the consumer. 



Issuer PIN 
check data 
length 104 



Length of PIN check data provided 
on card. If less than 16 digits, 
pad digits are added on the right 
by the terminal to provide an 8- 
byte field for DES encryption. 
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T-3 PIN Retry Number of field separators fco 

105 field on card containing T-3 

PIN Retry count. 

T-3 PIN Retry Displacement of t-3 Retry within 

Displacement the field on card, if this field 

is X'FF', the retry count in the 
customer options will be used. 



106 



T-3 Data Map Indicates which fields in T-3 are to 

107 be sent in the Transaction Request 

Message . 

Referring now to Figures 7A and 7B, the operation of the 
transaction execution system is illustrated. The customer ID 
card is read 110, and based upon track status and issuer 
identification a search 111 is ^ of local FIT table for the 
corresponding FIT entry. If a FIT entry is found 112 , trans- 
action data is collected 113 from, the card and from that 
entered at the keyboard to prepare a transaction request 
message for communication 114 to the host. At the host the 
customer account files are checked, and a transaction reply 
message returned 115 to the terminal including instructions on 
further execution of the transaction. The terminal executes 
the instructions, and returns to the host with a status 
message 116 indicating to the host the action taken so that 
the customer account fil es can be appropriately updated. 

In the event that a FIT entry corresponding to the 
customer ID card data had not been found, during the local FIT 
search, the terminal collects 117 the data required for a VFIT 
transaction request message to the host. That VPIN data 
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collection procedure is set forth in the flow chart of Figure 
9, which illustrates the selection 130-133 of T-2 and T-3 data 
in response to a control 128 provided previously from the host 
selecting the VP IN option. 

The terminal communicates 118 the VFIT transaction 
request to the host, which assembles from its files a trans- 
action reply 119 with an encrypted VFIT entry. The terminal 
validates 120 the VFIT entry, and communicates 121 to the host 
in a VFIT status message that the VFIT entry matches that 
requested and is otherwise accepted. If not instructed in 
VFIT transaction reply message to retain the card and/or 
terminate the transaction, the terminal proceeds to collect 
the transaction data and execute the request. If instructed 
to do so in the VFIT transaction reply message, at the con- 
clusion of the transaction execution, the terminal purges 122, 
123 from its local FIT table the VFIT entry received from the 
host. 

The transaction execution system described provides a 
self-service facility for customers of a financial institution. 
By using the terminal, many banking functions can be transacted 
without the aid of a teller and that twenty- four hours a day. 
A magnetic stripe card. with encoded identification data is 
issued to the customer by a financial institution, and used by 
the customer to initiate a transaction at the terminal. His 
identity is further verified by a personal identification 
number (PIN) , which he enters at the terminal keyboard. 

Sensitive data, including the identification data, is 
enciphered to help preserve its security. Encryption, and the 
subsequent decryption, is accomplished with an encryption 
algorithm and the institutions' secret encryption keys. The 
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system encryption algorithm may be selected to be the National 
Bureau of Standard's Data r„^ m . • National 
i*. hm * / Encryption Standard proposed algor- 

ithm, referred to as DES. 91 

Terminals may be used in an interchange environment- that 
° M " ^ <** <=«d holders from multiple. particLt 
=ardissuin 9 institutions can U se tne same terminal " 

t„„» A ^ " hile the customers 

transaction M maintained in the terminal, with an entry for 
many of the cooperating card issuing institutions accessed L 
the mstitution identifier read from the customer's card 2 
a search of that table does not find a mating entry, a request 

from the master table maintained there. After that master 
table entry ls used by the terminal, it may to pur(Jed 

sub^:t, e,,hMcin9 *• security ° f «■» »°=t <oT 

subhost) consumer m.s may be primed for handling a trans- 
action request from the terminal. 
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CLAIMS 



1. A transaction execution system comprising a transaction 
terminal for approval of a transaction and a host data proces- 
sing system in communication with the terminal, characterised 
in that the host data processing system (11) includes host 
storage means (10) for storing a plurality of issuer unique 
control blocks each including an encryption key, and in that 
the terminal (1) comprises terminal storage means (8) for 
storing a lesser plurality of issuer unique control blocks 
each including an encryption key, card reader means (2) for 
reading encoded data on an identification card presented to 
the terminal by an individual, the encoded data including 
issuer identification data and card verification data, means 
responsive to the issuer identification data for searching the 
terminal storage means (8) for a corresponding control block, 
means for communicating the encoded data to the host when a 
corresponding control block is not found in the terminal 
storage means and for receiving from the host a corresponding 
control block for writing into the storage means, and means 
(5) responsive to the encryption key data from the correspond- 
ing control block for encrypting the card verification data to 
generate a card check number. 



0003756 



- 2 - 



2. A system as claimed in claim 1. wherein each control 
block further includes identification card track format data 
the terminal including means responsive to the track format ' 
data for locating the card verification data for generating 
the card check number. 

3. A system as claimed in claim 1 or 2, further comprising 
means for receiving from the individual a respective pre- 
selected number, means for comparing the card check number and 
the pre-selected number and for generating an authorization 
signal, and means responsive to the authorization signal for 
approving a transaction requested by the individual. 

4. A system as claimed in any preceding claim, wherein the 
card reader means further includes means for reading encoded 
data from a plurality of data tracks on the card and for 
generating track status signals representative of the presence 
of data m the track and the readability of that track data 
wherein the issuer unique con.xol block further includes ' 
status data, and wherein the serening means is further 
responsive to the track status signals for searching the 
terminal storage means for a corresponding control block. 

5. A system as claimed in any Receding claim, further 
comprising means responsive to a command, received from the 
host in connection with communica.ion. from the host of a 
control block for purging the cont-oi block received from the 
host prior to completion of execution of a transaction. 

6. A system as claimed in claim 2, further comprising means 
responsive to card format data in th, corresponding control 
block for locating offset data in the wooded data and for 
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applying the offset data to one of the card check number or 
the pre-selected number prior to the comparison of the numbers. 

7. A system as claimed in any preceding claim, wherein each 
control block further includes transaction authorization 
parameter data, the terminal further comprising transaction 
execution means responsive to the transaction parameter data 
for approving a transaction requested by the individual. 

8. A system as claimed in claim 7, wherein the transaction 
authorization data specifies the location in the encoded data 
for accumulating the .number of failures of comparison between 
the card check number and the. pre-selected. number entered by 
the individual. 

9. A system as claimed in any preceding claim, further 
comprising register means for storing a communication encryp- 
tion key entered by a teller at the terminal or received by 
the terminal from the host, and means for encrypting data to 
be communicated to the host with the communication encryption 
key. 

10. A system as claimed in any preceding claim, further 
comprising register, means for storing a master encryption key 
entered by a teller at the terminal . or received by the term- 
inal from the host, and means responsive to the master encryp- 
tion key for encrypting data read from a control block to 
produce the encryption, key in clear text for encrypting the 
card verification data. 

11. A system as claimed in any preceding claim, further 
comprising means responsive to a command, received from the 
host in response to communication to the host of the encoded 
data for selectively retaining the identification card. 
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